* To do [0/5] [0%]

- [ ] data abstraction layer for things like the structure of a filters argument for ~GET~
  ~/containers/json~.

  If ~guile-json~ changes its Scheme representation of JSON values, we should be able to translate
  this docker API client by only changing things in one place, instead of having to change
  everything. The idea goes as follows:

  - We need some in-between object, which we define ourselves.
    - The in-between object can store arbitrary data, which is translated back to url-encoded
      (percent-encoded) JSON strings for use cases of the docker UNIX socket API.
  - This in-between object is used everywhere in the library, instead of building the expected
    structure for ~guile-json~ everywhere.
  - We write code to get the current ~guile-json~ Scheme JSON representation from the in-between
    object.
  - The in-between object should be very easy to create.
  - For now the in-between object can be just the representation the ~guile-json~ library makes use
    of. It only needs to be passed through a constructor and a transforming procedure, which both do
    no transformation, as there is no change in ~guile-json~ yet.

- [ ] Implement more routes to witness more (edge) cases to be able to choose good abstractions.

- [ ] Document the idea of having multiple levels of docker API calls (all routes, combination of
  routes, and higher level calls, which are arbitrary combinations of combinations of calls).

- [ ] Implement checks for arguments according to a defined docker UNIX socket API version.

- [ ] Define which docker UNIX socket API version the library is written to work with and pay
  attention to making it work with that version.
